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Abstract.  Deciding  equivalence  between  two  programs  (called  a  source 
and  a  target  program)  is  often  reduced  to  finding  a  simulation  relation 
between  them.  This  is  computationally  expensive  and  often  requires  a 
manual  guidance.  In  this  paper,  we  propose  an  abstraction-refinement- 
guided  approach,  called  SimAbs,  to  automatically  construct  a  simulation 
relation  between  the  source  program  and  an  abstraction  of  the  target 
program.  In  our  approach  both  the  abstraction  and  the  simulation  rela¬ 
tion  are  discovered  automatically,  and  deciding  whether  a  given  relation 
is  a  simulation  relation  is  reduced  to  deciding  validity  of  a  V3-formula. 
We  present  a  novel  algorithm  for  deciding  such  formulas  using  an  SMT- 
solver.  In  addition  to  deciding  validity,  our  algorithm  constructs  a  wit¬ 
nessing  Skolem  relation.  These  relations  enable  the  refinement-step  of 
SimAbs.  We  have  implemented  SimAbs  using  UFO  framework  and  Z3 
SMT-solver  and  applied  it  to  finding  simulation  relations  between  C  pro¬ 
grams  from  the  Software  Verification  Competition.  Our  empirical  results 
show  that  SimAbs  is  efficient  at  finding  a  simulation  relation. 


1  Introduction 

There  is  a  growing  interest  in  the  problems  of  regression  verification  and  pro¬ 
gram  equivalence  checking  [21, 22, 11, 14, 10, 20, 9].  In  general,  the  problem  is  to 
identify  (and  check)  the  condition  under  which  two  programs  (referred  to  as  the 
source  ( S )  and  the  target  (T))  are  equivalent  (i.e.,  satisfy  the  same  properties). 
These  approaches  prevent  the  wasted  efforts  in  re-analyzing  equivalent  parts  of 
the  programs.  For  instance,  while  proving  safety  of  two  closely  related  programs, 
obtaining  a  proof  of  one  program  and  adapting  it  to  another  program  can  be 
more  efficient  than  proving  each  program  from  scratch  (e.g.,  [10,9]). 

For  example,  in  [9]  we  applied  the  idea  of  adapting  proofs  to  analyze  whether 
compiler  optimizations  preserve  safety  properties.  While  efficient,  this  method 
had  a  number  of  limitations.  The  most  crucial  one  is  that  it  required  a  mapping 
between  variables  of  S  and  T  that  was  either  guessed  automatically  or  provided 
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Fig.  1:  (a)  SimAbs  and  (b)  its  search  space. 


by  the  user.  The  simplest  mapping  that  equates  variables  of  S  and  T  based  on 
their  names  (i.e.,  variable  a  of  S'  is  mapped  to  a  variable  a  of  T)  used  in  [9]  is 
often  insufficient.  In  practice,  it  sometimes  results  in  no  interesting  facts  lifted 
from  S  to  T .  As  an  example,  consider  compiler  spilling  that  may  introduce  many 
new  variable  names  in  T  that  did  not  appear  in  S. 

Namjoshi  et  al.  [19,20]  show  that  a  simulation  relation  is  the  most  general 
mapping  to  transfer  proofs  between  S  and  T.  However,  discovering  a  simulation 
relation  is  difficult  (e.g.,  [20]  expects  the  relation  to  be  provided  by  the  user). 
Moreover,  their  result  only  applies  when  T  actually  simulates  S,  whereas  we 
are  interested  in  cases  where  T  is  obtained  by  a  small  modification  from  S,  but 
might  not  simulate  S. 

In  this  paper,  we  address  two  problems:  (1)  the  challenge  of  automatically 
constructing  a  simulation  relation  for  two  arbitrary  programs,  and  (2)  if  the  tar¬ 
get  T  does  not  simulate  the  source  S ,  the  challenge  of  finding  a  strong  abstraction 
of  the  target  T  that  simulates  the  source  S. 

Our  main  contribution  is  an  iterative  abstraction-refinement  approach  called 
SimAbs,  illustrated  in  Fig.  la.  The  inputs  are  the  source  and  the  target  pro¬ 
grams  S  and  T,  respectively.  The  output  is  an  abstraction  of  T  (possibly  T 
itself)  that  simulates  S  and  a  simulation  relation  p,  or  a  step  of  S  that  cannot 
be  simulated  by  any  abstraction  of  T  (in  the  considered  space  of  abstractions). 
SimAbs  first  guesses  a  relation  p  between  S  and  T  (Synthesize  step).  Second,  it 
checks  whether  p  is  a  simulation  relation  between  S  and  the  current  abstraction 
of  T  (Solve  step).  Third,  if  the  check  succeeds,  it  refines  the  current  abstraction 
of  T  and  synthesizes  new  relation  p  (Refine  step).  Otherwise,  it  looks  for  a  bet¬ 
ter  abstraction  a  of  T  (Abstract  step).  The  algorithm  terminates  when  either 
no  refinement  or  no  abstraction  is  possible.  The  search  space  of  the  algorithm 
is  shown  in  Fig.  lb.  SimAbs  explores  the  space  of  abstractions  of  T,  starting 
with  the  most  general  abstraction  (called  aT  in  Fig.  lb)  that  simulates  S,  and 
iteratively  refines  it  until  no  further  refinement  is  possible. 

In  contrast  to  existing  algorithms  for  checking  whether  a  given  relation  p  is 
a  simulation  relation  (e.g.,  [18,13,21]),  we  reduce  the  problem  to  deciding  va- 
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lidity  of  a  V3-formula.  Intuitively,  the  formula  says  “for  each  behavior  of  S  there 
exists  a  corresponding  behavior  of  ]a]T”.  Our  second  contribution  is  a  novel  de¬ 
cision  procedure,  AE-VAL,  for  deciding  validity  of  V3-formulas  over  Linear  Real 
Arithmetic  (LRA).  Our  procedure  is  similar  to  the  QE_SAT  algorithm  of  [23]. 

However,  in  addition  to  deciding  validity,  we  also  extract  a  Skolem  relation  to 
witness  the  existential  quantifier.  This  Skolem  relation  (called  Sk  in  Fig.  la)  is 
the  key  to  the  Refine  step  of  SimAbs. 

We  implemented  SimAbs  and  AE-VAL  on  the  top  of  the  UFO  framework  [1, 

15]  and  an  SMT-solver  Z3  [8],  respectively.  We  have  evaluated  SimAbs  by  dis¬ 
covering  simulation  relations  between  programs  and  their  optimizations  (done 
by  LLVM).  Our  results  show  that  SimAbs  is  able  to  efficiently  discover  nontriv¬ 
ial  simulation  relations  between  the  original  and  the  optimized  versions  for  most 
of  the  benchmarks. 

The  rest  of  the  paper  is  structured  as  follows.  After  defining  notation  in 
Sect.  2,  we  describe  how  to  reduce  the  problem  of  checking  a  simulation  rela¬ 
tion  to  a  validity  check  of  a  specific  V3-formula  in  Sect.  3.  The  algorithm  AE- 
VAL  designed  to  solve  such  formulas  and  extract  Skolem  relation  is  presented 
in  Sect.  4.  Sect.  5  provides  implementation  details  for  the  algorithm  SimAbs. 

Sect.  6  presents  an  evaluation  of  our  implementation  of  SimAbs.  Sect.  7  com¬ 
pares  our  work  with  the  related  one,  and  Sect.  ??  concludes  the  paper. 

2  Background 

In  this  section,  we  give  the  necessary  definitions  of  a  program,  a  transition  sys¬ 
tem,  and  a  simulation  relation. 

Definition  1.  A  program  P  is  a  tuple  ( Var,  Init ,  Tr) ,  where  Var  =  V  U  L  U  V' 
is  a  set  of  current,  next-state,  and  local  variables,  respectively;  Init  is  a  formula 
over  V  that  defines  the  initial  state,  and  Tr  is  a  formula  over  Var  that  denotes 
the  transition  relation. 

Definition  2.  A  program  P  =  {Var,  Init,  Tr)  induces  a  transition  system  T  = 

(S,T,1Z),  where  S  is  a  set  of  valuations  to  all  variables  in  V  (i.e.,  states,), 

I  =  {s  £  S  |  s  ]=  Init}  is  the  set  of  initial  states,  7 Z  =  {(s,t)  \  s,t  €  S,3l  £  L  ■  Tr{s,  l,  t')} 
is  a  transition  relation.  Throughout,  we  write  S'  for  {s'  |  s  £  5},  and  t'  for  t{ x'). 

Definition  3.  Program  Pi  =  (V  U  L\  U  V' ,  Initi,  Trf)  is  an  abstraction  of  pro¬ 
gram  P‘2  =  (V  U  L2  U  V' ,  Init2,  Trf)  iff 

Init2  =>  Initi  (3I2  €  L2  ■  Tr2(s,  h,  s'))  =>  (3Zi  £  In  •  Tn {s,  h,  s'))  (1) 

An  example  of  abstraction  AQ  of  Q  is  shown  on  Fig.  2b-2c.  In  AQ,  non¬ 
determinism  is  introduced  on  the  level  go  the  input  parameters. 

Definition  4  (cf.[20]).  Given  two  transition  systems  S  and  T ,  a  relation  p  C  Ss  x  St 
is  a  simulation  relation  if  (1)  every  state  in  Is  is  related  by  p  to  some  state  in 
It,  and  (2)  for  all  states  s,  s'  and  t,  such  that  (s,t)  £  p  and  (s,  s')  £  IZs  there 
is  some  state  in  St  such  that  {t,t')  €  7 Zt  and  ( s',t ')  £  p. 
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int  P  (int  a, 

int  b,  int  c) 

{ 

int  m  =  b  +  c; 
int  ret  =  m  +  a; 
return  ret ; 


int  Q  (int  a, 

int  b,  int  c) 

{ 

int  m  =  a  +  b; 
int  n  =  c  +  1 ; 
int  ret  =  m  -  n; 
return  ret; 


int  AQ  (int  a, 
int  b,  *  ) 

{ 

int  m  =  a  +  b; 
int  n  =  c  +  1 ; 
int  ret  =  m  -  n; 
return  ret ; 


(a)  Source  program  P  (b)  Target  program  Q 


(c)  Abstraction  of  Q 


Fig.  2:  Fragments  of  the  three  programs  in  C 


We  write,  T\  T2,  to  denote  that  a  transition  system  T±  is  simulated  by  a 
transition  system  T2  via  a  simulation  relation  p.  We  write  T\  A  T2  to  indicate 
existence  of  a  simulation  between  T\  and  P2.  We  extend  the  notion  of  a  simulation 
from  transition  systems  to  programs  in  the  usual  way:  a  program  P\  is  simulated 
by  a  program  P2  iff  their  corresponding  transition  systems  simulate  each  other. 


Lemma  1 .  If  Pi  is  an  abstraction  of  P2  then  the  corresponding  transition  sys¬ 
tems  T2  -<id  T\,  where  id  is  the  identity  relation. 

Lemma  2.  If  T-\  A  P2  and  P2  A  P3  then  Xi  -<  T3. 


3  From  Simulation  to  Satisfiability 

In  this  section,  we  show  that  deciding  whether  a  given  relation  p  is  a  simulation 
relation  is  reducible  to  deciding  validity  of  a  V3-formula.  We  then  show  how 
Skolem  functions  witnessing  the  validity  of  the  quantifiers  can  be  used  to  refine 
a  given  simulation  relation. 


3.1  Deciding  Simulation  Symbolically 

Let  S(s,x,s')  and  T(t,y,t')  be  formulas  denoting  transition  relations  of  two 
programs,  where  s  and  t,  s'  and  f ,  x  and  y  are  current-state,  next-state,  and 
local  variables,  respectively.  Let  p(s,  t)  denote  a  relation  between  state  variables 
of  S  and  T.  For  simplicity,  we  omit  the  arguments  and  simply  write  S,  T,  and 
p,  when  the  arguments  are  clear  from  the  context. 

Lemma  3.  Given  programs  S  and  T,  a  relation  p  is  a  simulation  relation  be¬ 
tween  S  and  T  iff 

p(s,t)  A  3x  ■  S(s,x,s')  =>  3t',y  ■  T{t,y,t')  A  p(s',t')  (2) 

The  left-hand-side  of  implication  (2)  represents  the  set  of  all  behaviors  of  S 
and  the  set  of  all  matched  input  conditions.  The  right-hand-side  of  (2)  represents 
the  existence  of  a  matching  behavior  in  T. 
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Example  1.  Consider  two  programs  P  and  Q  shown  on  Fig.  2a  and  Fig.  2b,  re¬ 
spectively.  Their  corresponding  transition  relations  are  shown  in  (3): 

P  =  mp  =  bp  +  cp  A  retp  =  mp  +  ap  (3) 

Q  =  viq  =  aQ  +  bQ  A  riQ  =  cq  +  1  A  retQ  =  tuq  +  uq 

where  the  subscript  indicates  which  program  the  corresponding  variables  is  de¬ 
fined  in. 

Let  C  and  Af  be  relations  between  current  and  next-state  variables  of  P  and 
Q ,  respectively,  defined  as  follows: 

C  =  ap  =  aQ  A  bp  =  bQ  A  cp  =  cq  A f  =  retp  =  retQ  (4) 

Note  that  in  general,  unlike  in  our  simplified  definition  in  Section  2,  current  and 
next-state  variables  of  a  program  can  differ,  requiring  us  to  split  the  simulation 
relation  into  two  components. 

C  and  Af  is  a  simulation  relation  iff  the  following  formula  is  valid: 

C  A  (3mp  •  P)  =>  3retQ,mQ,riQ  ■  Q  A  Af  (5) 

Note  that  since  Q  is  deterministic,  the  existential  quantifiers  in  (5)  are  eliminated 
trivially  by  substitution.  In  our  example,  (5)  simplifies  to  0  =  1,  hence  C  and  Af 
is  not  a  simulation  relation  between  P  and  Q.  □ 

3.2  Abstract  Simulation 

In  this  section,  we  show  how  to  check  whether  a  given  relation  p  is  a  simulation 
relation  between  a  program  S  and  an  abstraction  aT  of  a  program  T.  We  restrict 
our  attention  to  existential  abstraction  [6],  although  the  results  extend  easily  to 
predicate  abstraction  as  well.  Our  key  result  is  to  show  that  simulation  checking 
can  be  done  without  constructing  an  abstraction  explicitly. 

Let  T  be  a  transition  relation  of  a  program,  and  U  a  sub-set  of  the  state- 
variables  of  T.  An  existential  abstraction,  ccy,  of  T  abstracts  from  T  all  variables 
in  U.  Formally,  a^(T)  =  3 U,U'  ■  T(t,y,t'),  where  U  C  t.  For  example,  the 
program  AQ  in  Fig.  2c  is  an  existential  abstraction  of  the  program  Q  in  Fig.  2b, 
where  U  =  { c} . 

Deciding  whether  a  given  relation  pa  is  a  simulation  between  a  concrete 
program  S  and  an  abstract  program  aT  can  be  done  without  computing  the 
abstraction  explicitly.  Intuitively,  the  variables  that  are  abstracted  away  are 
simply  treated  as  local  variables  of  T . 

Lemma  4.  Let  S(s,x,s')  and  T(t,y,t')  be  two  programs.  Let  U  C  t.  be  the  set 
of  abstracted  variables  and  t\  =  t\U .  A  relation  pa  is  a  simulation  relation 
between  S  and  a^-(T)  iff 

pa{s,t\)  A  S(s,x,s')  =>  3t'\,y,U,U'  ■  T(t,y,t')  Apafs',^)  (6) 
Proof.  Immediate  from  (2)  and  the  definition  of  existential  abstraction.  □ 
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Recall  that  in  Example  1,  program  P  was  shown  to  be  not  simulated  by  Q 
via  identity  relation.  Interestingly,  this  result  is  still  usefull  to  obtain  a  valid 
simulation  relation  between  P  and  Q  by  creating  implicit  abstraction  of  Q  and 
further  refining  it.  We  will  demonstrate  this  2-steps  procedure  in  Example  2. 

Example  2.  As  a  first  ( abstraction )  step,  we  create  an  implicit  abstraction  of  Q 
by  choosing  a  state- variable  (let  it  be  c)  to  be  existentially  quantified.  Note  that 
the  produced  abstraction  is  equivalent  to  AQ.  Instead  of  encoding  a  transition 
system  AQ  from  scratch  (similarly  to  (3)),  we  let  it  be  equal  to  AQ  =  3 cq  ■  Q 
Relation  C  and  A f  (disproven  to  be  a  simulation  relation  for  P  and  Q)  are 
abstracted  away  in  correspondence  with  AQ: 


Ca  =  aP  =  aQ  /\bP  =  bQ  Na  =  retP  =  retQ  (7) 

C  and  J\f  is  a  simulation  relation  between  P  and  AQ  iff  the  following  formula  is 
valid: 

C  A  (3m.p  ■  P)  =>  3cQ,retQ,mQ,riQ  ■  Q  AJV  (8) 

Clearly,  (8)  is  valid  iff  there  is  a  Skolem  function  for  the  existentially  quantified 
variable  cq.  Note  that  skCQ{cp )  =  —  cp  —  1  is  such  a  function: 

C  A  (3m p  ■  P)  ==>  (cq  =  - cP  -  1  ==>  3retQ,mQ,riQ  ■  Q  A  TV)  (9) 

As  a  second  ( refinement )  step,  skCQ  is  used  to  strengthen  a  simulation  relation 
C  and  Af  between  P  and  AQ. 

Cext  =  aP  =  aQ  /\bP  =  bQ  A  cq  =  -cP  -  1  N*xt  =  retP  =  retQ  (10) 

Note  that  and  J\f£xt  is  a  simulation  relation  between  P  and  Q.  □ 

Detailed  definition  of  the  Skolem  function,  its  generalization  and  application 
to  the  simulation-relation-checking  problem  is  given  in  Sect.  3.3. 


3.3  Refining  Simulation  by  Skolem  Relations 

In  this  section,  we  show  how  to  use  a  Skolem  relation  that  is  witnessing  the 
validity  of  the  abstract  simulation  check  (6)  to  refine  an  abstract  simulation 
relation.  We  begin  with  the  classical  definition  of  a  Skolem  function: 

Definition  5.  Given  a  valid  formula  \/x  ■  3 y  ■  f(x,  y),  a  Skolem  function  for  y, 
sky (x)  is  a  function  such  that  3y  ■  f(x,  y)  f(x,sky(x)). 

We  now  relax  the  definition  by  allowing  the  relationship  between  y  and  x  to  be 
an  arbitrary  relation: 

Definition  6.  Given  a  valid  formula  \/x  •  3y  ■  f(x,y),  a  Skolem  relation  for  y 
is  a  relation  Sky (x,y)  such  that  3y  ■  f(x,y)  *£=>  (Sky(x,y)  =>  f(x,y)). 
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To  see  that  Def.  6  is  a  generalization  of  Def.  5,  let  sky(x)  be  a  Skolem  function 
of  y  in  3 y  ■  f(x,y).  Then,  Sky(x,y)  =  (y  =  sky(x))  is  the  corresponding  Skolem 
relation. 


Sky{x,  y) 


y  =  sky(x) 


f(x,sky(x)) 


(11) 


Clearly,  the  opposite  is  not  true  -  not  every  relation  can  be  represented  by  a 
Skolem  function. 

As  shown  above,  a  Skolem  relation  eliminates  an  existential  quantifier  in  a 
valid  V3-formula.  In  fact,  validity  of  a  V3-formula  is  equivalent  to  an  existence 
of  an  appropriate  Skolem  function  (or  relation).  We  now  adapt  this  to  the  case 
of  simulation  checking. 

Theorem  1.  Let  S(s,x,s')  and  T(t,y,t')  be  two  programs  such  that  S  A  T, 
and  U  C  t.  Let  pa  be  a  simulation  relation  such  that  S  ^Pa  afr(T).  Then,  there 
exists  a  relation  Sk(s,  U)  such  that  (a)  pa  A  Sk  is  a  simulation  relation  between 
S  and  T  and  (b)  Sk  is  a  Skolem  relation  for  U  in  (6). 3 

Recall  that  by  Lemma  3,  simulation  checking  between  transition  systems  S 
and  T  is  reduced  to  deciding  validity  of  formula  (2).  In  the  next  section,  we  will 
focus  on  solving  (2)  by  iterative  quantifier  elimination  and  present  a  generalized 
algorithm  for  it. 


4  Deciding  Validity  of  V3-formulas  and  Extracting 
Skolem  Relations 

In  this  section,  we  present  a  novel  algorithm,  AE-VAL,  for  deciding  validity  of 
V3-formulas.  Without  loss  of  generality,  we  restrict  the  input  formula  to  the  form 
S(x)  =>  3 y  ■  T(x,  y),  where  S  has  no  universal  quantifiers,  and  T  is  quantifier- free. 


4.1  Deciding  Validity  of  V3-formulas 

Our  algorithm  is  based  on  a  notion  of  Model-Based  Projection  (MBP),  intro¬ 
duced  in  [15],  that  under-approximates  existential  quantification.  Let  M  be  a 
model  of  a  formula  T(x,y).  Then,  Ty(x)  is  an  MBP  if  the  following  two  condi¬ 
tions  hold:  (a)  M  \=  Ty(x)  and  (b)  T.y(x)  =>  3 y  ■  T(x,y).  That  is,  the  only  x 
variables  appear  in  T,  Ty,  M  is  a  model  of  Ty,  and  Ty  is  an  implicant  of  T.  Fur¬ 
thermore,  when  y  and  T  are  fixed,  MBP  is  finite.  That  is,  there  are  finitely  many 
projections  (x),Ty2  (£),...,  Tyn  (x)  such  that  (By  ■  T(x,  y))  =  V"=i  Tyt  (%)  f°r 
some  n.  In  our  implementation,  we  are  using  an  MBP  function  from  [15]  for 
LRA  that  is  based  on  Loos-Weispfenning  [16]  quantifier  elimination.  Addition¬ 
ally,  we  assume  that  for  each  projection  Tg.  the  MBP  procedure  produces  a 
local  Skolem  relation  4h(x,  y)  such  that  4>i(x,  y)  =>  (T.y.(x)  =>  T(x,y)).  Lo¬ 
cal  Skolems  are  a  natural  by-product  of  the  MBP  algorithm  in  [15].  We  write 

3  Due  to  lack  of  space,  the  proof  is  moved  to  Appendix  A. 
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Algorithm  1:  AE-VAL  {S(x),  By-  T(x,  y)) 


Input:  S(x),  By  •  T(x,  y) 

Output:  res  £  {valid,  invalid}  of  S(x)  =>  By  •  T(x,y) 
Data:  Incremental  SmtSolver,  Model  M, 

Model-based  projection  T$(x),  local  Skolem  relation  cf>i(x,y) 


1  SmtAssert(5(x)); 

2  while  true  do 

3  res  SmtSolve(); 

4  if  (isUNSAT(res))  then  return  valid; 

5  SmtPush(); 

6  SmtAdd  (T(x,y))-, 

7  res  SmtSolve(); 

8  if  (isUNSAT(res))  then  return  invalid; 

9  M  «—  SmtGetModel(T(z,  y)))-: 

10  T$,<j)(x,y)  <—  GetMBP (y,M,T{x,y)))\ 

n  SmtPop(); 

12  SmtAdd(^T^); 

13  end 


Fig.  3:  Illustration  to  Ex¬ 
ample  3  with  3  itera¬ 
tions  of  AE-VAL  (S,3T 
-  hexagons,  MBPs  -  ovals, 
models  -  points) 


(T),  (pi)  4—  GetMBP(j7,  M,  T(x,  y))  for  an  MBP  algorithm  that  takes  a  formula 
T,  a  model  M  of  T  and  a  vector  of  varialbes  y,  and  returns  a  projection  T)  of  T 
that  covers  M  and  the  corresponding  local  Skolem  </>,. 

AE-VAL  is  shown  in  Alg.  1.  Given  two  formulas  S(x)  and  By  •  T(x,y)  it 
decides  the  validity  of  S(x)  ==>  By  ■  T(x,y).  AE-VAL  enumerates  the  models 
of  S  AT.  In  each  iteration,  it  first  checks  whether  there  S  is  non-empty  (line  3) 
and  then  looks  for  a  model  M  of  SAT  (line  9).  If  M  is  found,  AE-VAL  constructs 
an  MBP  T$  of  T  and  M  (line  10)  and  blocks  all  models  contained  in  T$  from 
S  (line  12).  It  iterates  until  either  it  discovers  that  there  is  a  model  of  S  that 
can  not  be  extended  to  a  model  of  T  (line  8);  or  all  models  of  S(x)  are  blocked 
(line  4).  In  the  first  case,  the  formula  is  invalid.  In  the  second,  every  model  of  S 
has  been  extened  to  some  model  of  T,  and  the  formula  is  valid. 

Possible  three  iterations  of  AE-VAL  are  depicted  graphically  in  Fig.  3.  In 
the  first  iteration,  AE-VAL  selects  a  model  Mi  and  generalizes  it  to  an  MBP 
Tfc.  Then,  it  picks  a  model  M2  and  generalizes  it  to  an  MBP  T$2.  Finally,  it  picks 
a  model  M3  and  generalizes  it  to  T$3.  At  this  point,  all  models  of  S  are  covered 
by  y-free  implicants  of  T,  and  the  algorithm  terminates.  We  demonstrate  this 
further  in  the  following  example. 

Example  3.  Let  x  =  {a,  b},  y  =  {a7,  6',  c'},  and  S  and  T  be  defined  as  follows: 

S={a  =  b  +  2)  (12) 

T  =  (a'  =  a  +  b)  A  (a'  =  1  =>  b'  =  c')  A  (a'  =  2  =>  b'  =  c'  +  1)  A 
(o'  =  3  =>  b'  =  d  -  1) 

We  use  <3>i  to  denote  the  formula  in  the  SMT  context  at  the  beginning  of  iteration 
i  of  AE-VAL.  Initially,  =  S.  The  first  model  is  Mi  =  {a  =  0,  b  =  —2,  a1  = 


—2,  b'  =  0.  d  =  0}.  GETMBP(y,  Mi,T)  returns: 

T\  =  (a  +  b  ^  2)  A  (a  +  b  ^  3)  (f>i  =  (a1  =  a  +  b)  A  (b'  =  d)  (13) 

In  the  second  iteration,  ^2  =  $1  A-iTi,  M2  =  {a  =  2,  b  =  1,  a'  =  3,  b'  =  0,  c'  =  1}, 

and  GETMBP(y,  M2,  T)  returns: 

T2  =  (a  +  6  ^  1)  A  (a  +  6  ^  2)  c/>2  =  (a;  =  6  +  a)  A  (?/  =  d  —  1)  (14) 

In  the  third  iteration,  ^3  =  <£2  A  -iT2,  M3  =  {a  =  2,  b  =  0,  a'  =  2,  b'  =  1,  c'  =  0}, 

and  GETMBP(y,  M3)  T)  returns: 

T3  =  (a  +  b  d1  1)  A  (a  +  b  ^  3)  c/>3  =  (a7  =  a  +  b)  A  (?/  =  d  +  1)  (15) 

Since  <?4  =  <£3  A  -iT3  is  UNSAT,  EA-VAL  returns  Valid  and  terminates.  □ 


4.2  Extracting  Skolem  Relation 

In  the  previous  section,  we  have  shown  an  algorithm  AE-VAL  that  decides  va¬ 
lidity  of  S(x)  =>  3y  ■  T(x,y).  As  a  by-product,  it  constructs  a  set  of  MBPs 
{Tff.(x)}  for  T  and  the  corresponding  local  Skolem  relations  {<py.  (x,  y)}.  In  this 
section,  we  show  how  this  information  can  be  turned  into  a  Skolem  relation  Sky(x,  y). 

Intuitively,  Sk^j{x1  y)  maps  each  model  of  S'  to  a  corresponding  model  of  T. 
However,  the  local  Skolem  relation  (^^(x,  y)  provides  only  a  partial  map  (i.e., 
only  for  the  subset  S(x)  A T^j.{x)  of  S).  Moreover,  the  local  Skolem  relations  are 
not  disjoint  (e.g.,  see  Fig.  3).  Thus,  to  define  the  Skolem  relation  Sk,  we  need  to 
address  two  issues:  (1)  we  need  to  find  a  partitioning  {A:}”=1  of  S,  and  (2)  each 
partition  must  be  associated  with  an  appropriate  local  Skolem  relation. 

The  constraints  on  the  partitions  It  are  as  follows.  First,  a  partition  must 
cover  all  models  of  Tyt  that  are  not  already  covered  by  other  elements  of  the 
partition.  Second,  it  should  not  include  any  models  that  are  not  contained  in  Tjj.. 
Writing  these  requirements  formally,  we  get  the  following  system  of  constraints: 

'S(x)  A  %(£)  =>  Ix(x) 

S(x)  A  Tff2  ( x )  A  (£)  =>  I2{x) 


<  S(x)  A  T$n(x)  A  A  ~>T$2(x)  A  ...  A  ~‘T$n_1(x)  =>  /„(£)  (16) 

S(x)  A  I\(x)  A  (a;)  =>  T 

,S(x)  A  In(x)  A  ~>Tgn{x)  =>  JL 

Note  that  in  (16),  S  and  {Ty. }  are  first-order  formulas,  and  {A}  are  uninterpreted 
predicates.  The  set  of  constrains  corresponds  to  a  set  of  recursion-free  Horn 
clauses.  Thus,  we  can  find  an  interpretation  of  the  predicates  {/,}  using  a  Horn- 
clause  solver.  In  our  implementation,  we  use  the  solver  of  Z3,  but  other  solutions, 
for  example,  based  on  interpolation,  are  also  possible. 
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We  now  define  the  Skolem  relation  Skvy(x,y)  as  follows: 


{<t>vAx,y)  if  Ii(x) 

Sky(x,y)  =  l  •••  (17) 

[<j>yn{x,y)  else  if  In(x) 

The  following  two  theorems  show  the  soundness  and  completeness  of  our  Skolem 
relation  Skff(x,y).  Soundness  means  that  for  chosen  model  x,  Skg(x,y)  satisfies 
the  Def.  6.  Completeness  means  that  Sky(x,  y)  is  defined  for  all  models  of  x. 

Theorem  2  (Soundness  of  Skolem  Relation).  If  the  set  {/,(£)}  is  a  solution 
to  (16),  and  Skjj(x,y)  is  as  in  (17)  then:  S(x)  A  Sky(x,y)  =>  T(x,  y). 

Proof.  Simplifying  (17),  we  need  to  prove  that  for  every  1  <  i  <  n,  S(x)  /\Ii(x)/\ 
(f^ix^y)  =>  T(x,y).  It  is  enough  to  prove  that  for  every  i,  S(x)  A  Ii(x)  => 
T.ff.(x),  which  is  guaranteed  by  the  last  n  constraints  of  (16).  □ 

Theorem  3  (Completeness  of  Skolem  Relation).  If  the  set  {Ii(x)}  is  a 
solution  to  (16)  then  S(x)  =>  \/"  Ii{x). 

Proof.  Follows  immediately  from  the  first  n  constraints  of  (16).  □ 

Example  f.  A  partitioning  I\,  I2 ,  I3  that  determines  a  Skolem  relation  for  Ex¬ 
ample  3  is:  I\  =  (b  1)  A  (h  0),  I2  =  b  >  1,  and  J3  =  6  =  0.  □ 

Constructing  a  Minimal  Skolem  relation.  Any  solution  to  (16)  creates  a  Skolem 
relation.  But  not  all  Skolem  relations  are  equal.  In  practice,  we  often  like  a 
Skolem  relation  that  minimizes  the  number  of  variables  on  which  each  parti¬ 
tion  depends.  For  example,  in  Example  4,  we  have  chosen  a  partition  that  only 
depends  on  the  variable  b  alone.  A  simple  way  to  find  a  minimal  solution  is 
to  iteratively  restrict  the  number  of  variables  in  each  partition  in  (16)  until  no 
smaller  solution  can  be  found.  We  leave  the  problem  of  finding  the  minimum 
partitioning  for  future  work. 


5  Simulation- Abstraction-Refinement  Loop 

In  this  section,  we  present  our  algorithm  SimAbs  that  iteratively  constructs  and 
strengthens  a  simulation  relation.  While  so  far  we  have  assumed  that  a  program 
is  represented  by  a  single  transition  relation,  in  practice,  our  algorithms  operate 
on  the  Cut  Point  Graph  (CPG)  [12]  representation.  A  CPC  (or  a  Large  Block 
Encoding  (LBE)  [4])  is  a  generalization  of  a  Control  Flow  Graph  (CFG)  in  which 
nodes  (called  outpoints )  correspond  to  loop  heads  and  edges  to  longest  loop  free 
program  fragments.  In  this  section,  we  use  CPGs  informally  and  refer  the  reader 
to  [12]  for  the  formal  definition. 

The  main  loop  of  SimAbs  is  shown  in  Alg.  2.  The  input  is  two  programs  S 
and  T .  The  output  is  an  abstraction  aT  of  T  and  a  simulation  relation  pa  such 
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Algorithm  2:  SimAbs^,  T) 

Algorithm  3:  FindAbs(S,  T,  p) 

Input:  programs  S  and  T, 

abstraction  quality  metric  Q  :  a  {T,  _L} 

Output:  an  abstraction  aT, 

and  a  simulation  relation  pa ,  s.t.  5  -<Pa  aT 

1 

Input:  programs  S  and  T,  and  a  relation  p 
Output:  an  abstraction  aT, 
and  a  simulation  relation  pa,  s.t.  S  aT 

for  each  (u,  v)  £  E  do 

i 

p  «—  Synthesize(5,  T,  0); 

2 

if  ( ts(u,v )  p  tt(u,v))  then 

2 

while  (T)  do 

3 

aT  £-  Weaken(T); 

3 

aPreT  4 —  aT ; 

4 

if  (aT  U)  then 

4 

aT,pa  FindAbs(5',  T,/9a); 

5 

pa  <-  Synthesize(5,  aT,  0); 

5 

if  (aT  ^  HJ)  then  return  U,  0; 

6 

return  Find Abs(5,  aT,  pa) 

6 

aT,pa  Extend(5',  aT, /9q.); 

7 

else  return  U,  0; 

7 

if  ( Q(aT )  V  ( apreT  =  aT))  then  return  aT,  pa; 

8 

return  T,  p\ 

Algorithm  4:  Extend (S,aT,pa) 

Input:  S,  abstraction  aT,  simulation  relation  pa 
Output:  abstraction  aextT,  simulation  relation 

1  Pa*  <-  P «;  otextT  <-  aT- 

2  WL  <-  E  ; 

3  while  (WL  0)  do 

4  (u, v)  <-  GetWtoSmallestEdge(  WL); 

5  WL^  WL\{(u,v)}\ 

6  if  ( ts(u,v )  -<pext  Taext(j")(u,v))  then 

7  Sk  <-  ExtractSkolem(u,  v,  p If*); 

8  aextT  «—  Strengthen  (aT,  Sfc); 

9  pext  <-  Synthesize(5,  aT,  S7c); 

10  WL<r-  WLU{(v,x)  £  E\x£  CP}U{(y,u)  €  E  \  y  £  CP}; 

11  else  return  aT,pa\ 

12  return  aextT ,  pf* 


that  5  ^Po  T,  if  such  an  abstraction  exists.  In  the  presentation,  we  assume  that 
S  and  T  share  the  set  of  outpoints  CP,  but  might  have  different  interpretation 
of  control-flow  edges  by  loop-free  program  fragments.  However,  our  algorithm 
extends  to  the  general  case  where  S  and  T  have  different  outpoints  as  well. 

SimAbs  begins  by  guessing  an  initial  relation  p  using  Synthesize.  The  ini¬ 
tial  guess  can  be  an  arbitrary  relation  between  the  CPGs  of  S  and  T.  In  our 
implementation,  for  every  outpoint,  we  take  p  to  be  the  identity  relation  be¬ 
tween  the  live  variables  of  S  and  T  at  that  outpoint,  that  have  identical  names. 
Then,  SimAbs  uses  FindAbs  to  check  whether  there  exists  an  abstraction  of  p 
(including  p  itself)  that  is  a  simulation  relation  between  S  and  a  corresponding 
abstraction  aT  of  T.  If  this  succeeds,  the  method  Extend  is  used  to  refine  the 
abstraction  aT  and  synthesize  a  new  simulation  relation  pa.  This  process  con¬ 
tinues  until  the  abstraction  is  satisfied  by  some  quality  metric  Q  (line  7)  (for 
example,  if  it  is  sufficient  to  (dis-)prove  some  safety  property  of  T)  or  it  is  equiv¬ 
alent  to  an  abstraction  produced  in  the  previous  iteration  (line  3).  Otherwise, 
SimAbs  goes  into  the  next  iteration  and  finds  another  abstraction.  If  an  abstrac¬ 
tion  cannot  be  constructed  (we  use  a  shortcut  U  for  this),  SimAbs  terminates 
with  a  negative  result  (line  5). 

FindAbs  (shown  in  Alg.  3)  is  given  S,  T  and  p.  It  traverses  the  set  of 
CPG  edges  E,  common  to  S  and  T  (line  1)  in  the  Weak  Topological  Ordering 
(WTO)  [5]  (in  which  inner  loops  are  traversed  before  outer  loops).  For  each 
edge  (u,  v)  £  E,  FindAbs  checks  (on  line  2)  whether  p  is  a  simulation  relation 
between  the  loop-free  program  fragment  ts(u,v)  labeling  the  (it,  u)-edge  in  S 
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and  the  corresponding  loop-free  program  fragment  tt(u,v)  labeling  the  ( u,v)- 
edge  in  T.  If  the  check  succeeds  for  all  edges,  the  p  is  a  simulation  relation 
between  S  and  T ,  and  it  is  returned  to  the  user.  Otherwise,  FindAbs  chooses 
an  abstraction  aT  of  T  using  the  method  Weaken,  synthesizes  a  new  pa  and 
repeats  the  check  for  S,  aT,  and  pa.  Weaken  introduces  non-determinism  to 
the  interpretation  of  control-flow  edges  of  T.  In  our  implementation,  the  most 
successful  implementation  of  Weaken  is  the  existential  abstraction  of  all  state- 
variables  that  are  live  at  the  source  and  destination  of  the  edge  (u,  v)  for  which 
the  simulation  check  has  failed.  For  each  iteration  of  SimAbs,  FindAbs  is  given 
a  concrete  program  T,  and  always  constructs  a  new  abstraction  from  scratch. 

Extend  (shown  in  Alg.  4)  is  given  S,  aT,  and  pa  and  constructs  a  refine¬ 
ment  of  simulation  relation  pa  and  corresponding  refinement  aextT  of  aT. 
Extend  maintains  a  work-list  WL  of  control-flow  edges  to  be  processed.  Ini¬ 
tially,  WL  is  populated  with  all  the  CPG  edges  E  (line  2).  In  each  iteration, 
Extend  strengthens  aT  and  synthesizes  a  new  pa  by  strengthening  the  old  pa 
by  a  Skolem  relation  Sk.  Sk  is  produced  from  the  proof  of  the  simulation  between 
fragments  ts(u,  v )  and  TaT(u,  v)  of  the  smallest  element  (u,  v)  of  E  according  to 
the  WTO  (line  6).  Finally,  Extend  updates  WL  (line  10)  with  the  edges  that 
share  the  next-state  variables  that  have  appeared  in  Sk  and  iterates  until  WL  is 
empty.  If  in  some  iteration,  a  strengthening  is  impossible,  Extend  returns  the 
last  successful  values  for  pfxt  and  aextT. 

Recall  programs  P  and  Q  from  Fig.  2a  and  Fig.  2b.  In  Examples  1  and  2,  we 
proved  that  P  ■<  Q.  In  the  following  ,  we  show  how  SymAbs  automates  this. 

Example  5.  First,  SymAbs  is  given  P  and  Q;  Synthesize  guesses  C  and  Af  as 
in  (4).  Then  FindAbs  disproves  that  C  and  Af  is  a  simulation  relation,  but 
chooses  an  implicit  abstraction  of  Q  (equivalent  to  AQ  on  Fig.  2c),  and  constructs 
Ca  and  J\fa,  as  in  (7),  for  which  the  simulation-relation- formula  (8)  for  P  and  AQ 
is  valid.  Finally,  Extend  extracts  Skolem  relation  and  uses  it  to  create  C^xt  and 
A f^xt,  as  in  (10)  and  confirms  that  it  is  a  simulation  relation  for  P  and  Q.  □ 


6  Evaluation 

We  have  implemented  SimAbs  in  the  UFO  framework,  and  evaluated  it  on  the 
Software  Verification  Competition  (SVCOMP’14)  benchmarks  and  instcombine 
and  simpifycfg  optimizations  of  LLVM.  The  instcombine  performs  local  arith¬ 
metic  optimizations  (e.g.,  replacing  a  =  1  -  1  by  a  =  0).  The  simpifycfg  per¬ 
forms  dead  code  elimination  and  basic  block  merging  (e.g.,  replacing  if  (true) 
{a++;}  else  {a--  ;}  by  a++).  The  combination  of  these  optimizations  provides 
more  aggressive  optimizations. 

For  each  source  benchmark  ( S )  (300  -  5000  lines  of  source  code),  we  created  a 
target  optimization  (T)  by  two  applications  of  (instcombine  +  simpifycfg). 
We  applied  SimAbs  to  discover  two  simulations:  S  A  T  and  T  A  S.  Out  of  all 
benchmarks,  we  chose  157  for  which  SimAbs  terminates  within  5  minutes.  We 
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(a)  Simulation  of  S  by  T  (b)  Simulation  of  T  by  S 

Fig.  4:  Pie  chart  and  running  times  in  spherical  coordinate  system. 


present  the  results  in  two  diagrams  in  Fig.  4.  Full  results  are  available  at  http: 
//www . inf . usi . ch/phd/f edyukovich/ simabs .pdf4. 

Each  diagram  is  a  pie  chart  and  a  collection  of  SimAbs  execution  times  for 
each  benchmark  in  the  spherical  coordinate  system.  The  pie  chart  in  Fig.  4a 
represents  a  proportion  of  four  main  classes  of  SimAbs  results:  whether  (a- 
b)  T  simulates  S  (in  (a),  via  identity  relation),  (c)  T  does  not  simulates  S , 
but  some  abstraction  aT  does,  (d)  T  does  not  simulate  S  and  we  did  not  find 
an  abstraction  aT  that  does.  Each  dot  represents  a  runtime  of  SimAbs  on  a 
single  benchmark.  It  is  placed  in  one  of  the  segments  (a)-(d)  with  respect  to 
the  outcome,  and  is  assigned  the  unique  polar  angle  and  the  radial  distance  to 
represent  time  in  seconds.  For  example,  a  benchmark  on  which  S  ■< id  T  solved 
in  20s  is  placed  in  quadrant  (a)  in  a  distance  20  from  the  center.  Closer  to  the 
center  means  faster.  Runs  that  took  longer  than  60s  are  placed  on  the  boundary. 
Fig.  4b  is  structured  similarly,  but  with  inverse  order  of  S  and  T. 

The  experiment  confirms  our  intuition  that  the  original  program  more  often 
simulates  the  optimal  one  than  vice  versa.  According  to  Fig.  4,  in  115  cases 
S  A  aT ,  and  in  122  cases  T  A  aS ;  in  40  cases  S  ^  aT,  and  in  27  cases  T  ^  aS. 

The  experiment  confirms  that  the  use  of  our  novel  simulation-abstraction- 
refinement  loop  by  SimAbs  is  necessary  in  majority  of  cases.  There  is  a  relatively 
small  subset  of  benchmarks  (59  of  S  <  T  and  39  of  T  ■<  S),  in  which  the  identity 
relation,  guessed  at  the  first  iteration  of  SimAbs  is  already  a  simulation  relation 
(but  still,  in  many  cases  it  took  more  than  a  minute  to  establish  that),  while 
in  the  rest  of  the  cases,  SimAbs  goes  into  the  simulation-abstraction-refinement 
loop  and  successfully  terminates  (faster  than  a  minute). 

4  For  convenience,  we  have  included  the  table  of  results  in  an  appendix. 
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7  Related  Work 


The  algebraic  notion  of  simulation  relation  between  programs  dates  back  to 
Milner  [18].  The  approach  indirectly  refers  to  simulation  relation  between  S  and 
the  abstraction  of  T ,  by  introducing  weak  simulation,  and  to  simulation  relation 
between  S  and  T  as  strong  simulation.  While  being  purely  theoretic,  this  work 
does  not  consider  a  practical  application  of  using  weak  simulations  in  order  to 
construct  strong  simulation. 

Translation  Validation  for  optimizing  compiler  [21]  checks  simulation  relation 
between  a  program  and  its  GCC-optimization.  As  a  secondary  result,  that  work 
proposes  a  simple  heuristic  to  construct  simulation  relation,  restricted  to  specific 
optimizations.  Checking  is  done  on  the  level  of  control-flow  graphs  and  takes  into 
account  all  program  variables.  In  contrast,  our  SimAbs  algorithm  is  able  to  find 
simulation  relation  independently  on  an  optimizer. 

Classical  approach  to  check  that  a  relation  is  a  simulation  relation  is  by 
game- theoretic  approach,  in  which  the  state  space  of  the  source  and  the  target 
is  traversed  by  the  evader  and  a  pursuer  solvers.  For  instance,  [13]  applies  it  to 
prove  simulation  relation  between  infinite  graphs.  In  our  setting,  this  result  can 
used  to  extend  SimAbs  to  deal  with  programs  with  different  CPGs. 

The  need  of  eliminating  quantifiers  by  a  method  AE-VAL  makes  our  ap¬ 
proach  similar  to  template-based  synthesis  [24,  3, 2, 17].  The  goal  of  the  approach 
is  to  synthesize  an  arbitrary  program  that  fulfills  a  given  specification  repre¬ 
sented  by  a  template.  While  instantiating  existential  quantifiers,  synthesis  is  fill¬ 
ing  placeholders  in  the  predefined  template  formula.  While  discovering  a  Skolem 
relation  on  the  top  of  valid  simulation-relation-checking  formula,  we  also  perform 
a  synthesis,  but  do  not  require  any  template  for  it. 

Apart  of  discovering  simulation  between  programs,  there  exist  another  ways 
to  prove  their  equivalence.  For  example,  rather  practical  solution  to  check  equiv¬ 
alence  between  a  Verilog  circuit  and  C  program  was  established  in  [7] .  It  is  based 
on  translation  of  both  programs  into  quantifier-free  propositional  formula,  sat- 
isfiable  iff  the  circuit  and  the  program  disagree. 
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A  The  proof  of  Theorem  1. 


Theorem  1.  Let  S(s,x,s')  and  T(t,y,t')  be  two  programs  such  that  S  PT, 
and  U  C  t.  Let  pa  be  a  simulation  relation  such  that  S  afj(T).  Then,  there 
exists  a  relation  Sk{s,  U)  such  that  (a)  pa  A  Sk  is  a  simulation  relation  between 
S  and  T  and  (b)  Sk  is  a  Skolem  relation  for  U  in  (6). 

Proof.  Let  t  =  t\  U  U  and  t'  =  t\  U  U' .  Since  S  P  T,  there  exist  relation  p  such 
that  S  PpT  and  p  =>  pa.  Let  Sk  be  a  relation  over  s,  s' ,  U  and  U' ,  such  that 

p{s,t)  =  pa(s,t[)  A  Sk(s,U)  p{s',  t')  =  pa(s',  t'i)  A  Sk(s',  U')  (18) 

From  (2)  and  (18),  we  get 

Pa(s,  t\)  A  Sk(s,  U)  A  S(s,  s')  ==> 

3t[,  U’,y  ■  T(t[ ,  U,  y,  t{,  U’)  A  pa{s',  t[)  A  Sk(P,  U’)  (19) 

In  (19),  Sk  is  witnessing  a  Skolem  relation  for  U.  By  Def.  6,  we  get: 

3U  ■  pa{s,t[)  AS(s,  s')  => 

3  1^,  U',y-  T(ti,  U,  y,  t[,  U')  A  pa{s',  t[)  A  Sk(s',  U’)  (20) 

Since  (20)  is  valid  then  a  weaker  formula  (21)  is  also  valid. 

3U  ■  pa(s,  t[)  A  S(s,  s')  =>  3^,17,  U',y- T(^,C/,y,t,1,C//)  Apa(s/,t,1)  (21) 

Notably,  (21)  is  a  simulation-checking-formula  (6)  for  S  and  It  means, 

the  chosen  Sk  is  also  a  Skolem  relation  for  (6).  □ 

B  Concrete  data 

Tables  1,  2,  3  gather  statistics  for  all  3  cases  (S  <  T,  S  P  aT,  and  S  aT) 
respectively. 
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Table  1:  Full  cycle  of  SimAbs,  S  A  T 
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Table  2:  Full  cycle  of  SimAbs,  S  A  aT 
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